-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update location-retrieval with add maxSurface
management
#262
base: main
Are you sure you want to change the base?
Conversation
Add `maxSurface` management
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports |
@@ -525,6 +545,13 @@ components: | |||
status: 422 | |||
code: LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_AGE | |||
message: "Unable to provide expected freshness for location" | |||
LOCATION_RETRIEVAL_422_UNABLE_TO_FULFILL_MAX_SURFACE: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the calculated area violates both age and surface conditions, is the implementer free to choose which 422 code to return ?
As an implementation note, we could recommend to check the age condition first because area comparison can require more computation than age comparison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I've added a note: if both maxAge
and maxSurface
requirements fail, the system can either send back one or the other error code.
I agree on your recommendation but not sure if we have to add in the yaml as it is more for the system than the client.
Fixing linting + adding precision as suggested by @alpaycetin74: `Note: if both `maxAge` and `maxSurface` requirements fail, the system can either send back one or the other error code. `
Fix linting error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with minor correction and comment
|
||
maxSurface: | ||
type: integer | ||
minimum: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what would be realistically the minimum that a "best" implemention may provide, but likely above 100 m2. We may set 1 here and let implementations provide the minimum supported separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we allow a min radius of 1 probably we cannot have a min of 100m2. Probably good to add an note indicating that implementations will provide minimum.
Co-authored-by: Jose Luis Urien <[email protected]>
Add a note for maxSurface minimum allowed.
Co-authored-by: Jose Luis Urien <[email protected]>
* **Max Surface**: Maximum surface in square meters which is accepted by the client for the location retrieval. | ||
|
||
* absence of `maxSurface` means that "any surface size" is acceptable for the client. | ||
* API implementation could specify in the documentation the `maxSurface` minimum acceptable (for exemple minimun of 10000 square meters allowed). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to propose a minor rewording here, and fixing some typos:
API implementation could specify the minimum acceptable maxSurface
in the documentation (for example a minimum of 10000 square meters are allowed).
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
add
maxSurface
managementWhich issue(s) this PR fixes:
Fixes #255
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.